Jen pro představu, násobení matic ­(stažené ze stránek NVIDIE­) je na GeForce 9600 GT asi 140× rychlejší než na 3,0GHz Core 2 Duo :­-)

Pokud jste srovnával pouze běh na grafice a emulovaný běh, tak to máte pravdu. Součástí zdrojového kódu je i rutina pro kontrolní výpočet na cpu ­(computeGold­). Pokud si změříte, jak to dlouho trvá jí, zjistíte podstatně rozdílné číslo;­-)

Tak jsem si to zkusil znova. Emulovaný běh nepoužívám, protože se mi bije s knihovnami OpenCV, které v programu používám a zatím se mi to nechtělo řešit.
Takže, GPU ­(pouze samotný výpočet funkce Muld zopakovaný několik tisíc krát­) ­- 0,043 ms na jeden výpočet.
CPU ­(30× zopakovaná funkce ComputeGold­) ­- 3,633 ms na jeden výpočet
Tudíž, tentokrát mi to vyšlo 85× rychleji na GPU.

Tyhle výsledky mě dokáží vždycky šokovat a překvapit a přiznávám se, že se mi stále nezdají. Jak může být grafika tolikrát silnější? Není ten test silně optimalizován na GPU? Běží na tom CPU na všech jádrech? Používá instrukce SSE? je zvláštní, proč toto GPU, při zhruba 10x vyšším teoretickém výkonu, má skoro 100x vyšší výkon. Neví někdo v čem je zakopán pes? V nepodpoře MADD instrukce dnešními procesory? Ve schopnosti GPU počítat plno instrukcí v jednom taktu? Nebo v čem?

Pokud to budete zpracovávat v SSE, a řekněme na dvou jádrech, můžete dosáhnout 8× zrychlení ­(teoreticky­). Jedno jádro má 128­-bitovou SSE jednotku, tedy najednou může pracovat na 4 32­-bitových floatech ­(desetinných číslech­). Máme­-li dvě jádra, teoreticky můžeme zrychlit aplikaci osmkrát. Ve skutečnosti je zrychlení v aplikacích spíše jen v desítkách procent než v násobcích. Pokud ale máte algoritmus, který SSE jednotkám skutečně perfektně padne, lze dosáhnout až 31× násobného zrychlení na jediném jádře ­(ač teoreticky SSE mohlo v dané situaci zrychlit aplikaci jen 16×­).
Co se týče grafik, máte k dispozici jen u GeForce 9600 GT celých 64 shaderů. Každý tento shader může zpracovávat až 96 vláken najednou, to máte 6144 vláken najednou. Řekněme, že zpracováváme obraz 1024×768 pixelů, tj. 786 tisíc pixelů a hodnoty jsou v charech ­(8­-bitové proměnné­). U procesoru s SSE a dvěma jádry tedy můžeme zpracovat najednou 2 ­(jádra­) * 16 ­(do 128­-bitového registru se vejde 16 8­-bitových proměnných­), tedy 32 pixelů.
Na zpracování 786 tisíc tedy CPU potřebuje 24500 cyklů ­(786000­/32 = cca 24500­), kdežto GPU potřebuje jen 128 cyklů ­(786000­/6144 = 128­). Hned máte 200­-násobné zrychlení ­(teoreticky­). Pokud budou hodnoty ve floatech, tak procesor začne o to více prohrávat, neboť do SSE registru se nevejde 16 proměnných, ale jen 4 ­(float má 32 bitů­). Pak by teoretický rozdíl byl 800­-násobný. Pochopitelně v praxi jsou dosažena jiná čísla, ale je skutečnost, že GPU díky masivnímu paralelismu zvládá zpracování objemných dat někdy až neskutečně rychle.

S tímhle se dá souhlasit, ale čísla 64 a 96 bych nenásobil přímo:­) Z pohledu CUDY na GTX280, je k dispozici 30 multiprocesorů a na každém z nich v jednu chvíli běží šestnáct vláken. Pokud je procesor náležitě vytížen větším počtem vláken, tak dochází k schedulingu a procesory se tváří, že na nich běží víc vláken, ale ani tak bych nešel k vyšším číslům řekněme než 64 ­(samozřejmě závisí na úloze­). Možná se pletu, o grafiky jsem se nezajímal do doby, než jsem na nich začal počítat, tak mě když tak opravte:­)
Mám ten dojem totiž, že i oficiální materiály pro CUDU uvádějí maximální teoretické zrychlení 100krát, a když se podíváte na některé projekty na stránkách CUDY, tak obvykle u nich můžete vidět čísla velikosti několika desítek.

Tak tohle opravdu nechápu. Tedy chápu to všechno až na to množství vláken u jednoho shaderu. Kde jste přišel na to, že jeden shader v GeForce 9600GT může pracovat na 96 vláknech zároveň? Pokud se nepletu, shadery v GeForce 9600GT jsou skalární a obsahují jednu ALU co umí počítat zároveň násobení a sčítání ­(MADD, nebo­-li FMA instrukci­) a ještě jednu jednodušší ALU jednotku, co umí asi jen sčítat. Tím si nejsem jist, ale to je vlastně jedno. Jde o to, že pokud mám správné informace ­(čímž si nemohu být jist­), shadery v této grafárně jsou prostě jednoduchá zařízení a že by mohly pracovat zároveň na 96 vláknech zároveň, je opravdu nejaké divné. Leda teoreticky z podledu SW, ale bude jim to ve skutečnosti trvat spoustu cyklů, protože víc jak dvě výpočetní jednotky ten shader nemá.

Já osobně bych rozdíl výkonu mezi tímto CPU a GPU počítal takto:

Teoretický výkon CPU pro desetinná čísla: 2 jádra * 2 instrukce za takt ­(Ono Core 2 tedy zvládne 4, ale má tuším jen 3ALU pro celá čísla a 2FPU jednotky pro desetinná­) * 4 složkový vektor ­(128bitové SSE­) * 3 GHz = 48GFLOPs

Teoretcký výkon pro GeForce 9600GT: 64 shaderů * 3 instrukce za takt ­(MADD jsou dvě + jedna jednoduchá na sčítání­) * 1625MHz * 1 ­(jsou skalární, tedy žádné vektory­) = 312GFLOPs.

Tímto výpočtem mi vyjde GPU jako 6,5x výkonnější. Teoreticky samozřejmně a za předpokladu že počítají s 32bitovými floaty. A to mi právě přijde divné. Pokud k dobru CPU člověk připočte OoO zpracování, lepší předpověď větvení, různé predikce, cache, atd, měl by se ten 6,5 násobný rozdíl zredukovat. tahle úvaha má ale k praxi, kde je GPU skoro 100x výkonnější, daleko. Jediné co mě napadá, že některé výpočty zvládá GPU v jednom taktu, kdežto CPU ne. POkud vím, tak hlavně na dělení a odmocniny potřebuje CPU několik desítek taktů. GPU mají tuším v HW speciální jednotku na počítání speciálních funkcí ­(odmocniny, exp, sin, atd...­), což by jim mohlo dost pomoci. Svou roli může hrát i ta MADD instrukce ­(násobí a sčítná­), což se prý u operací s maticemi velice často používá. Na Anandtechu jsem kdysi četl, že například kryptování urychluje asi 5x ­( http:­/­/www.anandtech.com­/showdoc.aspx?i=3073&p=3 ­).

Váš výpočet se mi zdá až na těch 96 vláken správný. Jestli mi ukážete, že jak shader v 9600GT zvládne počítat těch 96 vláken zároveň, rád uznám že se pletu.

Zkuste se podívat na http:­/­/www.nvidia.com­/docs­/IO­/47906­/220401_Reprint.pdf. Konec stránky číslo 2 v levém sloupečku. Přiznávám však, že do architektury NVIDIA CUDA teprve jen začínám pronikat a naprogramoval jsem jen jednoduché urychlení ještě djednoduššího výpočtu.

Jafpu ma pravdu. 96 threadu sice to GPU umi, ale rozhodne ne v jednom taktu. Chtelo by to trosku zdraveho rozumu ;­).

Co se tyce toho srovnavani, tak to nelze delat podle teoretickych cisel. GPU jsou lepe vyladeny pro masivni vypocty. Prakticky kazdy takovy vypocet dosahuje skoro 100% efektivity ­(hodne nezavislych prokladanych threadu, hodne registru, optimalizovany scheduler, optimalizovana instrukcni sada ­[az ctyri operandy, FMA, instrukce jako skalarni soucin atp.­], vysoka propustnost pameti­). U CPU hodne zalezi na urovni rucni optimalizace a maximalnim vyuziti vsech dostupnych instrukci. Zadny kompilator nedokaze z CPU vymacknout maximum. Z mych zkusenosti vyplyva, ze rucni optimalizace C++ kodu s vyuzitim SSE­(2,3,4­) vede bezne k 5­-10nasobnemu zrychleni. Spousta algoritmu je taky bandwidth­-limited. CPU tedy porad ceka na data z RAM a flaka se. Dalsim problemem je malo registru ­(zejmena v 32­-bitovem modu­) a pouze 2­-operandove instrukce ­(tohle resi AVX a SSE5­).

Třeba takové Visual Studio dokáže optimalizovat kód až nezvykle dobře. Snažil jsem se ručně naprogramovat kód v assembleru co nejlépe, ale maximálně jsem se optimalizaci Visual Studia vyrovnal, ale nepřekonal. SSE kód lze psát buď ve formě céčkovských funkcí ­(pomalé­) nebo přímo v assembleru, což je rychlejší a skutečně se tak dá dosáhnout výrazného zrychlení. Co se týče malého množství registrů, máte naprostou pravdu. I poměrně jednoduchý výpočet má tolik různých odkládacích a dočasných proměnných, že počty registrů nestačí.

Z tohoto pohledu jsem celkem zvědav, co předvede Sandy Bridge s AVX instrukcema. Vyjma rozšíření na 256 bitů, bude zajímavá právě ta schopnost pracovat s třemi a čtyřmi operandy, plus nějaká nedestruktivní syntaxe ­(nejsem si jist o co jde­). Počítám, že ve vhodně optimalizovaných aplikacích, to přinese dost brutální nárůst výkonu. Pokud vím, tak právě pro FMA instrukci je třeba schopnosti pracovat s třemi operandy. Bohužel, FMA instrukci Intel neimplementuje hned do první generace Sandy Bridge, ale prý až do další. Nechápu proč. Že by to byl takový problém? Je snad ta instrukce natolik zásadní, že je kvůli ní potřeba upravit další věci? Například že by se kvůli ní stali jiné instrukce zbytečné a je třeba je odstranit? Nevím.
Pokud jde o ty registry, narazil jste na problém, co mě dlouho vrtá hlavou. Na začátek musím upozornit, že narozdíl od vás dvou, neprogramuji a ani se v HW neangažuji, takže na to mám zcela laický pohled. x86 architektura je sice omezena na 8 GP registrů ­(16 u x64­), ale pokud vím, je to jen vnější pohled. x86 procesory už dlouho používají featůru přejmenování registrů. P4 jich mělo tuším 128 ­(nevím kolik jich má Core 2­), pro programátora a kompilátor se ukazovalo sice jen těch 8, ale HW si do těch zbývajících už potřebná data nachystal a v případě potřeby registry přejmenoval, aby byla data ihned dostupná a nebylo je třeba tahat z relativně pomalé cache. Něco podobného mimochodem používají i CPU Power od IMB. Tam jsou omezeny na 32 registrů, což je sice lepší než u x86, ale ideální to taky není. Tady se naskýtá otázka, jak moc je viditelnost dalších registrů jen pro HW a né pro kompilátor a programátora nevýhodná. Vy byste to snad mohl objasnit.

Prejmenovani registru se pouziva pro out­-of­-order zpracavani. Kdyz ma programator ­(nebo prekladac­) malo viditelnych registru, tak musi pouzit vice instrukci a vic pristupu do pameti ­(nekdy dokonce i jiny algoritmus­). Vsechno tohle ale procesor musi provest. On si kod nemuze a ani nesmi nijak upravit.
Tou nedestruktivnosti se mysli to, ze jeden operand neni soucasne cilovy a zdrojovy. Napr. FMA bude tedy pouzivat 4 operandy. U GPU a RISC normalni vec. Jinak, nevim, proc bude FMA az u naslednika Sandy Bridge ­(Ivy Bridge ?­), ale rekl bych, ze Intel novinky davkuje postupne. FMA navic vyzaduje netrivialni zmeny v architekture.